OpenEdge Development:<br />Messaging and ESB Finding administered objects in JNDI or proprietary directories

Release 10.1A: OpenEdge Development:
Messaging and ESB

Finding administered objects in JNDI or proprietary directories

A JMS-administered object is an object created by a JMS administrator and registered with a directory (typically a JNDI-compliant directory) under a name that is meaningful to the JMS clients. The object contains JMS configuration information that is created by a JMS administrator and later used by JMS clients. Java Naming and Directory Interface (JNDI) is an interface for JMS administrators to create and configure administered objects and store them in a namespace.

The SonicMQ-administered objects are:

TopicConnectionFactory

QueueConnectionFactory

Topic

Queue

For example, the administrator creates a TopicConnectionFactory object, which contains all the JMS server connection parameters (communication protocol host and port), assigns it a name, and stores it in a JNDI directory. The client does not have to know the connection parameters to connect to the JMS server. The client finds the object by name in the directory and uses it to create connection objects. The administrator can change the connection parameters later without affecting client applications.

The administrator can give the Topic and Queue objects meaningful aliases to shield the client from their internal names. For example, a topic with the internal JMS name of sports.USA.Northeast.golf could be stored in the directory under northern.golfers. For more information on administered objects, see the Java Message Service specification, SonicMQ Programming Guide , and SonicMQ Configuration and Management Guide .

Using the OpenEdge Adapter for the SonicMQ and the 4GL-JMS API with administered objects

JMS does not impose any specific directory for storing administered objects (although it establishes the convention of using JNDI-compliant directories, such as LDAP). Also, the process of connecting to a JNDI server and obtaining an initial context is not standardized.

Therefore, to use directory-stored JMS objects, you must implement a Java class, compile it, and install the class file on the OpenEdge Adapter for the SonicMQ host under the OpenEdge Adapter for the SonicMQ’s CLASSPATH. (For more information on CLASSPATH, see the "Setting the CLASSPATH" section.) The OpenEdge Adapter for the SonicMQ looks for that class when it starts up. If it finds the class, it creates an instance object of it and uses it to locate administered objects. If it does not find the class, the OpenEdge Adapter for the SonicMQ creates objects as required.

jmsfrom4gl.AdminObjectFinder class

The following code is the skeleton of the jmsfrom4gl.AdminObjectFinder class. Use it as a template to create a class file and install it on the OpenEdge Adapter for the SonicMQ host; Unified Broker host for BrokerConnect, 4GL client host for ClientConnect, and AppServer or WebSpeed Transaction server host for the ServerConnect option.

The jmsfrom4gl.AdminObjectFinder name is mandatory. The class and the get...() methods must be declared public. The AdminObjectFinder class must be part of the jmsfrom4gl package and placed in a directory called jmsfrom4gl. The directory that contains jmsfrom4gl must be on the CLASSPATH of the OpenEdge Adapter for SonicMQ. For example:
package jmsfrom4gl; 
import javax.jms.TopicConnectionFactory; 
import javax.jms.QueueConnectionFactory; 
import javax.jms.Topic; 
import javax.jms.Queue; 
public class AdminObjectFinder 
{ 
  public TopicConnectionFactory getTopicConnectionFactory(String name) 
    throws Exception 
  { 
    TopicConnectionFactory factory = null; 
    // Write code to populate factory 
    return factory; 
  } 
  public QueueConnectionFactory getQueueConnectionFactory(String name) 
    throws Exception 
  { 
    QueueConnectionFactory factory = null; 
    // Write code to populate factory 
    return factory; 
  } 
  public Topic getTopic(String name) 
    throws Exception 
  { 
    Topic topic = null; 
    // Write code to populate topic 
    return topic; 
  } 
  public Queue getQueue(String name) 
    throws Exception 
  { 
    Queue queue = null; 
    // Write code to populate queue 
    return queue; 
  } 
} 
Notes: The brokerURL startup parameter is used as the input parameter for the getTopicConnectionFactory and getQueueConnectionFactory methods. For example, if the 4GL application calls the setBrokerURL procedure passing in the input parameter directory_factory_name, the 4GL-JMS implementation on the server side calls the getTopicConnectionFactory method with directory_factory_name as the parameter.

If the getTopicConnectionFactory and getQueueConnectionFactory methods are implemented, the jmsServerName startup parameter is ignored (since the identity of the server’s vendor is encapsulated in the object).

It is sufficient to implement methods for those objects that should be obtained from the directory. For example, it is legal to have an AdminObjectFinder class with only the getTopicConnectionFactory method. The 4GL-JMS implementation looks for the methods dynamically and does not fail if the other methods are missing.

If the object finder method returns null, the 4GL-JMS implementation tries to create the object as if the method is not there.

For more information on CLASSPATH, see the "Setting the CLASSPATH" section.